Skip to content

[AMD][dsv4] fix 2P1D 8k1k straggler (decode/prefill context-length asymmetry)#2257

Closed
inkcherry wants to merge 1 commit into
SemiAnalysisAI:mainfrom
inkcherry:pr/dsv4-straggler-fix
Closed

[AMD][dsv4] fix 2P1D 8k1k straggler (decode/prefill context-length asymmetry)#2257
inkcherry wants to merge 1 commit into
SemiAnalysisAI:mainfrom
inkcherry:pr/dsv4-straggler-fix

Conversation

@inkcherry

@inkcherry inkcherry commented Jul 17, 2026

Copy link
Copy Markdown
Contributor

In the 2P1D 8k1k run at concurrency 500/512 a few requests hang until the client timeout (p99.9 TTFT ~1800s).

models.yaml sets context_length: 9217 on the prefill role only, and server_sglang.sh only passes --context-length to prefill, so decode falls back to the model default (~1M). A request longer than 9216 is accepted by decode (allocates KV, waits for the transfer) but rejected by prefill with HTTP 400, so prefill never sends the KV and that decode request waits forever.

Changed

Also pass --context-length to decode (read from models.yaml, defaulting to the prefill value) so both sides use the same limit.

Validated

Before: conc-500 stalled with 33/1000 (rr=1.0) and 4/1000 (rr=0.8) requests hung to the timeout. After: conc-500 and conc-512 complete 100% in ~140s with normal p99.9. gsm8k accuracy unchanged (0.958).

…aggler)

Satisfies MOTIVATION_RULES rule 2 (root cause) + rule 3 (fix).

Root cause of the 8k1k conc-500/512 straggler tail (last few requests hang to the
1800s client timeout, p99.9 TTFT ~1802s): a prefill/decode context-length
asymmetry. models.yaml sets context_length: 9217 for the DeepSeek-V4-Pro prefill
role but not the decode role, and server_sglang.sh only appends --context-length
to PREFILL_MODE_FLAGS. So prefill runs with context_length=9217 (max input 9211)
while decode falls back to the model's default (~1M; observed max_req_input_len
1048570). A request whose input exceeds 9211 -- e.g. random-dataset prompts that
retokenize above the 8192 target -- is ACCEPTED by decode (which pre-allocates KV
and waits for the transfer) but REJECTED by prefill with HTTP 400 (so prefill
never registers the bootstrap room and never sends KV). The decode request then
waits forever for a KV transfer that never comes and hangs to the client timeout.
(The permanently-pending decode requests also re-query the prefill bootstrap
every scheduler iteration, which is what exhausted ephemeral ports in a separate
failure mode addressed by the bootstrap-session-pool patch.)

Fix: parse a decode context_length from models.yaml and append --context-length
to DECODE_MODE_FLAGS, defaulting to the prefill value when unset so the two roles
always agree in PD-disaggregation. Over-length requests now fail fast at decode
admission (HTTP 400) instead of hanging. Valid requests are unaffected.

@claude claude Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Claude Code Review

This pull request is from a fork — automated review is disabled. A repository maintainer can comment @claude review to run a one-time review.

ichbinblau added a commit that referenced this pull request Jul 21, 2026
- Speed circuit-breaker recovery and gate benchmarking on an end-to-end
  router readiness canary, so a transient trip or a not-yet-serving
  router doesn't 503 every request until the client's retry budget is
  exhausted (port of PR #2255).
- Keep decode's admission context-length symmetric with prefill
  (falling back to prefill's value when unset in models.yaml), so
  over-length requests are rejected fast by both sides instead of
  hanging on decode while waiting for a KV transfer prefill never
  sends (port of PR #2257).

Co-authored-by: Cursor <cursoragent@cursor.com>

Co-authored-by: inkcherry <mingzhi.liu@amd.com>
@inkcherry

Copy link
Copy Markdown
Contributor Author

included in #2293, closed.

@inkcherry inkcherry closed this Jul 21, 2026
adibarra pushed a commit that referenced this pull request Jul 22, 2026
…ncy sweep (#2293)

* [AMD][dsv4] fix 2P1D eval 503s and 8k1k straggler tail

- Speed circuit-breaker recovery and gate benchmarking on an end-to-end
  router readiness canary, so a transient trip or a not-yet-serving
  router doesn't 503 every request until the client's retry budget is
  exhausted (port of PR #2255).
- Keep decode's admission context-length symmetric with prefill
  (falling back to prefill's value when unset in models.yaml), so
  over-length requests are rejected fast by both sides instead of
  hanging on decode while waiting for a KV transfer prefill never
  sends (port of PR #2257).

Co-authored-by: Cursor <cursoragent@cursor.com>

Co-authored-by: inkcherry <mingzhi.liu@amd.com>

* add con=500/512

Signed-off-by: Theresa Shan <theresa.shan@amd.com>

* set max_total_tokens: 2097152

Signed-off-by: Theresa Shan <theresa.shan@amd.com>

Co-authored-by: lixiufei-leo <Xiufei.Li@amd.com>

* update config

Signed-off-by: Theresa Shan <theresa.shan@amd.com>

* [AMD][dsv4] Replace 2P1D DEP8 sweep with 1P1D pure-TP8 in disagg non-MTP search space

Drop the 2P1D DEP8 (conc 256/512/1024) and 1P1D DEP8 conc=1024 entries
and add a 1P1D pure-TP8 (no EP, no DP-attention) scenario sweeping
conc [1, 2, 4, 8, 16, 32, 64, 128] for dsv4-fp4-mi355x-sglang-disagg.

Co-authored-by: Cursor <cursoragent@cursor.com>

* remove decode context_length

Squash of f7295a5 "remove decode context_length", 0be1d30
"Revert 'remove decode context_length' for DeepSeek-V4-Pro", and
bfb8988 "remove decode context_length ending with a newline" into
a single commit with the same net result.

Signed-off-by: Theresa Shan <theresa.shan@amd.com>
Co-authored-by: Cursor <cursoragent@cursor.com>

* Add perf-changelog.yaml entry for dsv4-fp4-mi355x-sglang-disagg retune

Per the automated PR reviewer: any edit to configs/amd-master.yaml
requires a paired perf-changelog.yaml entry. Documents the 503/
straggler-tail fixes, the max_total_tokens bump, and the 2P1D DEP8 ->
1P1D DEP8/pure-TP8 concurrency sweep retune from PR #2293.

Co-authored-by: Cursor <cursoragent@cursor.com>

* Guard router readiness canary with wait_or_die on prefill0_pid

The canary poll loop was a plain while/curl loop, unlike every other
blocking wait on node rank 0 (container barrier, servers-up barrier,
/readiness health barrier), so a prefill crash right after /readiness
passed just looked like repeated 503s and burned the full
ROUTER_CANARY_TIMEOUT (default 600s) instead of failing fast. Extract
the loop into run_router_canary() and run it under wait_or_die so a
dead prefill pid aborts it in ~5s like the surrounding barriers.

Co-authored-by: Cursor <cursoragent@cursor.com>

---------

Signed-off-by: Theresa Shan <theresa.shan@amd.com>
Co-authored-by: inkcherry <mingzhi.liu@amd.com>
Co-authored-by: lixiufei-leo <Xiufei.Li@amd.com>
Co-authored-by: Cursor <cursoragent@cursor.com>
Co-authored-by: Chun Fang <chun.fang@amd.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Development

Successfully merging this pull request may close these issues.

1 participant